home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / telecomm / fnorddel / fn132man.zoo / chapter.02 < prev    next >
Text File  |  1991-09-02  |  27KB  |  601 lines
  1.  
  2.  
  3. Chapter 2:  Sysop Theory                                                  14
  4.  
  5.  
  6.  
  7.  
  8. 2  Sysop Theory
  9.  
  10.  
  11.    Before getting into the  nitty-gritty details of what buttons to  push to
  12. get which  results, let us  first force down your  throat some theory  about
  13. what you're going  to be dealing with.   You can  forget about it after  the
  14. final exam, if you wish.
  15.  
  16.  
  17. 2.1  Your Callers
  18.  
  19.    You are presumably  going through all  of this because  you wish to  have
  20. people of  some type  call your  system and  do something  with it.    These
  21. callers are  your reason  for running  a BBS.  While other  systems offer  a
  22. vast array of  access and status levels,  the general Citadel philosophy  of
  23. simplicity holds  here, meaning  that there  are no  real preferential  user
  24. access levels.
  25.  
  26.    Despite that  fact,  there do  need to  be some  ways  to handle  special
  27. cases.   See Section 5.2 [User Status  Commands], page 80, for  the commands
  28. to assign the various  user attributes.  As of this writing,  the attributes
  29. are:
  30.  
  31.   o __The Sysop__.   That's you, the  System Operator, and there's  only one
  32.     of you unless  you share the duties with other people, or  somebody else
  33.     has access  to your computer while it's  running Fnordadel.  You  can do
  34.     anything  within reason,  and a  few things  beyond reason.    Fnordadel
  35.     allows  you to  define the  name used  by the  Sysop in  `ctdlcnfg.sys',
  36.     using the  parameter #sysop.   You should  set this up  correctly.   (If
  37.     your system  really has more  than one Sysop,  set the #sysop  parameter
  38.     to  whichever one has  direct access to  the system  or uses the  system
  39.     most,  or just pick  a name  from a  hat.   Alternatively, leave  #sysop
  40.     undefined.   See Chapter 5 [The  Sysop Command Reference], page 75,  for
  41.     more discussion on Sysop matters.)
  42.  
  43.   o __Co-Sysops__.    You may  additionally designate  any  number of  other
  44.     users  on  your  system  as  ``Co-Sysops'',   by  assigning  them  Sysop
  45.     privileges.   This means that  they have virtually unlimited ability  to
  46.     use any command,  *except* those in the Sysop menu (accessed by  `^L' at
  47.     the main  room prompt).   To let  such people have  access to the  Sysop
  48.     menu as  well, you need  to give them  the system password.   Note  that
  49.     anyone who has  been given Sysop privs is also automatically  given Aide
  50.     privs.
  51.  
  52.   o __Aides__.   These are  people that you wish  to have help you  operate,
  53.     maintain and control your system.  They can  do things like delete, copy
  54.     or  move messages, and  they may do  a certain  amount of room  editing,
  55.     floor maintenance  and other things.   In  general, however, they  can't
  56.     do much  to change the  basic nature of things  (e.g.  alter  networking
  57.     parameters, do things involving access to your storage devices, etc.).
  58.  
  59.   o __Twits__.   These are users that  you have decided are too  detrimental
  60.     to have  continued access to  your system, but  whose user accounts  you
  61.     don't simply wish to kill, lest they immediately  sign back on again and
  62.     continue where they  left off.  Twits have most commands  disabled; this
  63.     includes the ability to post messages!
  64.  
  65.  
  66.  
  67. Chapter 2:  Sysop Theory                                                  15
  68.  
  69.  
  70.  
  71.  
  72.   o Everybody else.   This  is the group  of people who  are not the  Sysop,
  73.     Co-Sysops,  Aides,  or Twits.    They  comprise the  bulk of  your  user
  74.     population, most likely.
  75.  
  76.    Additionally, the  Sysop has control  over users'  ability to do  certain
  77. things like  send private  mail, create  new discussion rooms,  and post  in
  78. networked  rooms.    (Such  rooms may  well  be connected  to  long-distance
  79. systems, and  we don't want  irresponsible or evil  users causing big  phone
  80. bills!)
  81.  
  82.    When you first  start your system, it is  unlikely that you will wish  to
  83. grant Aide  or Co-Sysop  status to many  of your users,  since you  probably
  84. won't know many of them at  all well.  Our advice is to take your  time, and
  85. pick out some people  who will handle the positions responsibly.   If chosen
  86. wisely, they  will be  an asset in  controlling your system,  and in  making
  87. creative contributions which prevent stagnation.
  88.  
  89.  
  90.  
  91. 2.2  Rooms
  92.  
  93.    Right from the start, Citadel made use of something  called a __room__ to
  94. contain messages on a related  topic.  Fnordadel does the same.  A  room has
  95. a name up to 19 characters in length, which presumably  captures the gist of
  96. a topic to be discussed by the messages in that room.   Some systems you may
  97. be familiar with make use of ``message areas'',  ``message bases'', ``SIGs''
  98. (Special Interest Groups), etc.  They are all  basically analogous to rooms,
  99. but will typically be few in number and cover broad, static topics.
  100.  
  101.    Other systems make use  of ``threads'', in which messages are  related to
  102. each other  by a  common subject  field (for example)  rather than  physical
  103. location.   Callers travel up  and down the threads  one message at a  time,
  104. and now and then jump  to a new thread.  Still other systems have  no way to
  105. organise messages;  they are all  stored in one giant  mass that is hard  to
  106. wade through as a user, and still preserve one's sanity.
  107.  
  108.    We  feel that  Citadel's room  metaphor  is much  easier  to use  than  a
  109. threading scheme, offers better organization than one  massive message area,
  110. and permits  better dynamic flow  of discussion than  bulky SIGs or  message
  111. bases.
  112.  
  113.    As callers  use your system,  they will  move from  room to room  reading
  114. new messages,  and posting  replies as  they see  fit.   If the  topic of  a
  115. room drifts  off on  a tangent  (as is common),  you as  Sysop may  exercise
  116. control to bring it back on track, change its name to  suit the new trend of
  117. discussion, move the  off-topic messages into a newly-created room,  or kill
  118. the room entirely if none of the above options are worth the effort.
  119.  
  120.    The basic room  can be specialised  in a number  of ways to meet  various
  121. needs.  Some of the attributes are:
  122.  
  123.   o __Permanent__.  Normally, empty rooms will be  purged by the system from
  124.     time to time.   There is also  a command for doing this  explicitly (see
  125.     .A(ide)  D(elete-empty-rooms) in  Section 4.1.2  [The .A(ide)  command],
  126.     page 63).  You may not always wish rooms  to disappear if they go empty,
  127.     so you may designate them permanent, and they will stick around.
  128.  
  129.  
  130.  
  131. Chapter 2:  Sysop Theory                                                  16
  132.  
  133.  
  134.  
  135.  
  136.   o __Anonymous__.    Rooms  of this  type are  used  for discussions  where
  137.     callers  may wish to  remain totally unidentified.    None of the  usual
  138.     message  header information is  stored or  shown by the  system, just  a
  139.     message number.
  140.  
  141.   o __Private__.   These rooms are for carrying out activities that  are not
  142.     to be viewed by  all callers to the system.  Only users who  are told of
  143.     the complete room name  are able to get into it.  And once  a user knows
  144.     the room's name,  he can't be barred from it short of altering  the name
  145.     and reinviting all the other users.
  146.  
  147.   o __Invitation-only__.   These rooms  are just like  the above type,  with
  148.     one difference.  Users must be invited into  them with a system command;
  149.     knowing the full name  is not sufficient to gain access.  If  a caller's
  150.     presence is  no longer desired,  eviction from the  room is also  easily
  151.     possible, without choosing a new room name.
  152.  
  153.   o __Read-only__.    Rooms  of this  type can  only  have messages  entered
  154.     in  them by  the Sysop,  Co-Sysops or Aides.    A typical  use for  such
  155.     a  room is for  announcements that you  wish people  to have access  to,
  156.     uncluttered by comments from other callers.
  157.  
  158.   o __Directory__.   Rooms of this type  are used to give callers  access to
  159.     your storage device(s)  (RAM, disk or hard drives), for the  purposes of
  160.     file uploading  and/or downloading.   Each directory  room is tied to  a
  161.     specific  disk directory  somewhere, so  you can  give different  people
  162.     access to different collections of files.   Normal discussion activities
  163.     are permissable in directory rooms.
  164.  
  165.   o __Network__  or __Shared__.    Rooms of  this  type are